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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document describes an extension to the Open Shortest Path First 
(OSPF) protocol to allow a single physical link to be shared by 
multiple areas. This is necessary to allow the link to be considered 
an intra-area link in multiple areas. This would create an intra- 
area path in each of the corresponding areas sharing the same link. 
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1. Introduction 
1.1. Motivation 


It is often a requirement to have an Open Shortest Path First (OSPF) 
[OSPF] link in multiple areas. This will allow the link to be 
considered as an intra-area path in each area and be preferred over 
higher cost links. A simple example of this requirement is to use a 
high-speed link between two Area Border Routers (ABRs)in multiple 
areas. 


Consider the following topology: 


RI------- Backbone------ R2 
| | 
Area 1 Area 1 
| | 
R3SSa Sass Area 13--—2--- R4 


Multi-Link Topology 


The backbone area link between R1 and R2 is a high-speed link, and it 
is desirable to forward Area 1’s traffic between R1 and R2 over that 
link. In the current OSPF specification [OSPF], intra-area paths are 
preferred over inter-area paths. As a result, R1 will always route 
traffic to R4 through Area 1 over the lower speed links. R1 will 
even use the intra-area Area 1 path though R3 to get to Area 1 
networks connected to R2. An OSPF virtual link cannot be used to 
Solve this problem without moving the link between R1 and R2 to Area 
1. This is not desirable if the physical link is, in fact, part of 
the network's backbone topology. 


The protocol extension described herein will rectify this problem by 
allowing the link between R1 and R2 to be part of both the backbone 
area and Area 1. 


1.2. Possible Solutions 


For numbered interfaces, the OSPF (Open Shortest Path First) 
specification [OSPF] allows a separate OSPF interface to be 
configured in each area using a secondary address. The disadvantages 
of this approach are that it requires additional IP address 
configuration, it doesn't apply to unnumbered interfaces, and 
advertising secondary addresses will result in a larger overall 
routing table. 
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Allowing a link with a single address to simply be configured in 
multiple areas would also solve the problem. However, this would 
result in the subnet corresponding to the interface residing in 
multiple areas that is contrary to the definition of an OSPF area as 
a collection of subnets. 


Another approach is to simply allow unnumbered links to be configured 
in multiple areas. Section 8.2. of the OSPF specification [OSPF] 
already specifies that the OSPF area ID should be used to de- 
multiplex received OSPF packets. One limitation of this approach is 
that multi-access networks are not supported. Although this 
limitation may be overcome for LAN media with support of "Point-to- 


Point operation over LAN in link-state routing protocols" [P2PLAN], 
it may not be acceptable to configure the link as unnumbered due to 
network management policies. Many popular network management 


applications individually test the path to each interface by pinging 
its IP address. 


1.3. Proposed Solution 


ABRs will simply establish multiple adjacencies belonging to 
different areas. Each multi-area adjacency is announced as a point- 
to-point link in the configured area. However, unlike numbered 
point-to-point links, no type 3 link is advertised for multi-area 
adjacencies. This point-to-point link will provide a topological 
path for that area. The first or primary adjacency using the link 
will operate and advertise the link in a manner consistent with RFC 
2328 [OSPF]. 


1.4. Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in RFC 2119 
[RFC-KEYWORDS]. 


2. Functional Specifications 
2.1. Multi-Area Adjacency Configuration and Neighbor Discovery 


Multi-area adjacencies are configured between two routers having a 
common interface. On point-to-point interfaces, there is no need to 
configure the neighbor's address since there can be only one 
neighbor. For all other network types, the neighbor address of each 
multi-area adjacency must be configured or automatically discovered 
via a mechanism external to OSPF. 
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2.2. Multi-Area Adjacency Packet Transmission 


On point-to-point interfaces, OSPF control packets are sent to the 
AllSPFRouters address. For all other network types, OSPF control 
packets are unicast to the remote neighbor’s IP address. 


2.3. Multi-Area Adjacency Control Packet Reception Changes 


Receiving protocol packets is described in Section 8.2 of [OSPF]. 
The text starting with the second paragraph and continuing through 
the third bullet beneath that paragraph is changed as follows: 


Next, the OSPF packet header is verified. The fields specified in 
the header must match those configured for the receiving interface. 
If they do not, the packet should be discarded: 


o The version number field must specify protocol version 2. 


o The Area ID found in the OSPF header must be verified. If all of 
the following cases fail, the packet should be discarded. The 
Area ID specified in the header must either: 


1. Match the Area ID of the receiving interface. In this case, 
the packet has been sent over a single hop. Therefore, the 
packet’s IP source address is required to be on the same 
network as the receiving interface. This can be verified by 
comparing the packet’s IP source address to the interface’s IP 
address, after masking both addresses with the interface mask. 
This comparison should not be performed on point-to-point 
networks. On point-to-point networks, the interface addresses 
of each end of the link are assigned independently, if they 
are assigned at all. 


2. Indicate a non-backbone area. In this case, the packet has 
been sent over a multi-area adjacency. If the area-id matches 
the configured area for a multi-area adjacency, the packet is 
accepted and is from now on associated with the multi-area 
adjacency for that area. 


3. Indicate the backbone. In this case, the packet has been sent 
over a virtual link or a multi-area adjacency. 


o For virtual links, the receiving router must be an ABR, and the 
Router ID specified in the packet (the source router) must be the 
other end of a configured virtual link. The receiving interface 
must also attach to the virtual link's configured transit area. 

If all of these checks succeed, the packet is accepted and is from 
now on associated with the virtual link. 
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o For multi-area adjacencies, if the area-id matches the configured 
area for the multi-area adjacency, the packet is accepted and is 
from now on associated with the multi-area adjacency for that 
area. 


o Note that if there is a match for both a virtual link and a multi- 
area adjacency then this is a configuration error that should be 
handled at the configuration level. 

o Packets whose IP destination is AllDRouters should only be 
accepted if the state of the receiving interface is DR or Backup 
(see Section 9.1 of [OSPF]). 

o [...] The remainder of Section 8.2 of [OSPF] is unchanged. 

2.4. Interface Data Structure 

An OSPF interface data structure is built for each configured multi- 

area adjacency as specified in Section 9 of [OSPF]. The interface 

type will always be point-to-point. 
2.5. Interface FSM 


The interface Finite State Machine (FSM) will be the same as a point- 
to-point link irrespective of the underlying physical link. 


2.6. Neighbor Data Structure and Neighbor FSM 


Both the neighbor data structure and neighbor FSM are the same as for 
standard OSPF, specified in Section 10 of [OSPF]. 


2.7. Advertising Multi-Area Adjacencies 
Multi-area adjacencies are announced as point-to-point links. Once 
the router’s multi-area adjacency reaches the FULL state, it will be 
added as a link type 1 to the Router Link State Advertisement (LSA) 
with: 
Link ID = Remote’s Router ID 


Link Data = Neighbor’s IP Address or IfIndex (if the underlying 
interface is unnumbered). 


Unlike numbered point-to-point links, no type 3 link is advertised 
for multi-area adjacencies. 


Mirtorabi, et al. Standards Track [Page 6] 


RFC 5185 OSPF Multi-Area Adjacency May 2008 


3. Compatibility 


All mechanisms described in this document are backward compatible 
with standard OSPF implementations [OSPF]. 


3.1. Adjacency Endpoint Compatibility 


Since multi-area adjacencies are modeled as point-to-point links, it 
is only necessary for the router at the other end of the adjacency to 
model the adjacency as a point-to-point link. However, the network 
topology will be easier to represent and troubleshoot if both 
neighbors are symmetrically configured as multi-area adjacencies. 


4. OSPFv3 Applicability 


The mechanisms defined in this document also apply to OSPFv3 
[OSPFV3]. As in OSPF, a multi-area adjacency is advertised as a 
point-to-point link in the advertising router’s router-LSA. Since 
OSPFv3 router-LSA links are independent of addressing semantics and 
unambiguously identify OSPFv3 neighbors (refer to Section 3.4.3.1 of 
[OSPFV3]), the change to router-LSA links described in Section 2.7 is 


not applicable to OSPFv3. Furthermore, no prefixes corresponding to 
the multi-area adjacency are advertised in the router's intra-area- 
prefix-LSA. 


A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The 
neighbor's IPv6 link local address can be learned in other ways, 
e.g., it can be extracted from the IPv6 header of Hello packets 
received over the multi-area adjacency. The neighbor IPv6 link local 
address is required for the OSPFv3 route next-hop calculation on 
multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]). 


5. Security Considerations 


This document does not raise any security issues that are not already 
covered in [OSPF] or [OSPFV3]. 
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